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ABSTRACT 


This thesis is an enhancement to the Air Tasking Order 
(ATO) Optimization Model, a linear integer optimization 
model that seeks to match the best air assets against the 
highest priority targets. The ATO Optimization Model was 
written as a 1993 Master's Thesis to help the Joint Forces 
Air Component Commander in wargames rapidly produce an ATO. 
The model was used in the global wargame SEACON 93 but some 
difficulties were encountered. Asset utilization was 
restricted by the static structure of the model and attempts 
to coerce the model into doing dynamic scheduling were 
unsuccessful. Additionally, the model's implementation 
required the user to have unrealistically extensive 
knowledge of the software being used, DBASE IV and GAMS. 
This thesis addresses these difficulties. First, it 
explicitly incorporates the time dimension in the 
optimization model, thereby allowing multiple sorties per 
aircraft per day, something that was not allowed in the 
static model. Second, a graphical user interface has been 
built around the optimization model to alleviate the need 
for the user to have a strong background in database or 
optimization software. The enhanced model produces 
face-valid results that are readily usable within 
high-pressure, fast-paced environments, such as a global 


■game. 
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EXECUTIVE SUMMARY 


In both the real world and wargames, an integral part 
of theater level warfare is the coordinated use of air 
assets against the enemy. This coordination is done by the 
Joint Forces Air Component Commander, or JFACC, in the form 
of an Air Tasking Order, or ATO. The ATO is an air plan of 
all the events required in strike planning. It assigns the 
air assets of the various warfare commanders to target 
strikes and support missions. 

The slow, labor intensive and inefficient manual method 
of ATO production observed by Lt. Matthew Dolan during his 
experience tour at the Naval War College led to the creation 
of the Air Tasking Order (ATO) Optimization Model, a Naval 
Postgraduate School Master's Thesis. The ATO Optimization 
Model is a linear integer optimization model that seeks to 
find the best match of the available assets to targets and 
missions. 

During SEACON 93 the Naval War College attempted to 
implement the ATO Optimization Model in a production 
wargame. While able to make effective use of the model, 
several difficulties were encountered. 

Dolan's model is a static model, intended for use over 
a short duration, so it ignores the possibility of multiple 
sorties by the same aircraft. However in SEACON 93, the 
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was used for pi 


longer period (24 hours) and 


this omission was problematic. 

The second difficulty in SEACON 93 with the original 
ATO model dealt with the construction of the DBASE IV 
databases and their subsequent inclusion in the optimizer 
input file. The process of extracting the database 
information into a usable input to the optimizer was very 
manpower intensive and required detailed knowledge of DBASE 
IV and GAMS. It was recognized that requiring the user to 
have a working knowledge of both database and optimization 
software could invalidate the usefulness of the ATO model. 

The enhancements to the Dolan model center on the 
incorporation of a time dimension, changing it from a static 
model to a dynamic one. In the original model, time on top 
(TOT) was not a consideration. The demand for strike 
packages was specified by location only. Now, demand is 
specified by both time (TOT) and location. Additionally, by 
incorporating the time dimension aircraft are now considered 
available to fly multiple sorties in a day. The 
availability of aircraft in each period depends on previous 
decisions concerning the times when aircraft launch and 
return. 

With these enhancements, planners in the JFACC cell 
will have a better feel for how assets are being utilized 
and will be better able to track the number of sorties 




available for add-on or contingency plans. In addition, 
sortie launch times are computed, which speeds up data entry 
by personnel on the game floor. 

To alleviate the user's need for a strong understanding 
of a commercial database program and the GAMS optimization 
software, a user-friendly graphical interface was developed 
using Visual Basic for Windows. The interface provides easy 
to use data entry screens for inputting the required data, 
creates the input file needed for the optimization program 
with a "click" of the mouse, and reproduces the results of 
the model in several formats that are useful and informative 


for the game players. 



I. INTRODUCTION 


In both the real world and wargames, an integral part 
of theater level warfare is the coordinated use of air 
assets against the enemy. This coordination is done by the 
Joint Forces Air Component Commander, or JFACC, in the form 
of an Air Tasking Order, or ATO. The ATO is an air plan of 
all the events required in strike planning. It assigns the 
air assets of the various warfare commanders to target 
strikes and support missions. 

In the fall of 1992, while on a Naval Postgraduate 
School experience tour, Lt. Matthew Dolan observed the ATO 
production during the SEACON 92 wargame at the Naval War 
College. The slow, labor intensive and inefficient manual 
method of ATO production he observed led to the creation of 
the Air Tasking Order (ATO) Optimization Model [Ref.l], a 
Naval Postgraduate School Master's Thesis. The ATO 
Optimization Model is a linear integer optimization model 
that seeks to find the best match of the available assets to 
targets and missions. The model requires the following 
data: launch site locations, type and number of aircraft or 
Tomahawk assets available at each launch site, asset ranges, 
refueling requirements, number of refuelings allowable per 
mission, target/mission identification 


and 




target/mission priority, target/mission types, strike 
packages and strike package preference. 

During SEACON 93 the Naval War College was attempting 
to implement the ATO Optimization Model in a production 
wargame. While able to make effective use of the model, 
several difficulties were encountered. 

Dolan's model is a static model, intended for use over 
a short duration, so it ignores the possibility of multiple 
sorties by the same aircraft. However in SEACON 93, the 
model was used for planning a longer period (24 hours) and 
this omission was problematic. An attempt to coerce the 
model into scheduling two sorties per aircraft by doubling 
the size of the available pool was unsuccessful because it 
led to simultaneous flights of more assets than really 
existed. 

The second difficulty in SEACON 93 with the original 
ATO model dealt with the construction of the DBASE IV 
databases and their subsequent inclusion in the optimizer 
input file. The process of extracting the database 
information into a usable input to the optimizer was very 
manpower intensive and required detailed knowledge of DBASE 
IV and GAMS. It was recognized that requiring the user to 
have a working knowledge of both DBASE and GAMS could 


invalidate the 


ifulness of the ATO model. 



This thesis presents two major enhancements to Dolan's 
ATO Optimization Model. First, it incorporates the time 
dimension and enables the user to model over any time period 
deemed necessary. Time on target (TOT) is a centerpiece of 
the model. Planners in the JFACC cell need the time 
dimension in order to have a better feel for how assets are 
being utilized and to track the number of sorties available 
for add-on or contingency plans. In addition, sortie launch 
times are computed in the enhanced model, which speeds up 
data entry by the personnel on the game floor. 

The second enhancement is a user friendly graphical 
interface which provides for better understanding of the 
database structure and enables the user to construct a data 
file in the proper format for GAMS implementation. The user 
is able to import the optimized ATO schedule and produce 
flight schedules in several different formats for use by the 
various game players. The interface package surrounding the 
GAMS model is written in VISUAL BASIC for Windows. 
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II. FORMULATION 


A. APPROACH 

The purpose of the optimization model is to find the 
best match of the available assets to designated targets and 
missions, and to schedule launches so as to meet the 
required times on target (TOT). During data entry, 
discussed fully in Chapter II, targets and missions are 
grouped into different target/mission types. Each 
target/mission type has several different strike packages, 
consisting of different types and numbers of assets, that 
are capable of performing the mission. If multiple assets 
of a single type are required then these assets must all 
launch from the same site. This is called a single sourcing 
constraint and reflects the actual practice, whenever 
possible, of aircrews briefing a mission together and helps 
maintain flight integrity. The various strike packages are 
compared against the availability of the assets that make up 
the strike packages to meet the TOT. The model selects the 
most desirable strike packages (for a given target type) 
available and attempts to strike all targets. If there are 
insufficient assets to hit all targets the highest priority 
targets are struck first. 



The enhancements to the Dolan model center on the 
incorporation of a time dimension, changing it from a static 
model to a dynamic one. In the original model, TOT was not 
a consideration. The demand for strike packages was 
specified by location only. Now, demand is specified by 
both time (TOT) and location. Additionally, by 

incorporating the time dimension, aircraft are available to 
fly multiple sorties in a day, an aspect that the original 
model did not allow. The time element is achieved in the 
following way: 

• The 24 hour day is segmented into X number of periods, 
each period representing 24/X hours. 

• Each target or mission is assigned a Time on Target 

(TOT), which is converted to the proper period (POT). 

• The time, as measured in periods , required by a strike 
package to fly to the target, called the fly out time 
(EOT), and the total cycle time (CT), which includes 
the time required to fly to and from the target plus 
any on station time (ST) is computed. 

• The period when the aircraft will have to launch, if 
assigned, is determined for each potential launch site 
and eligible asset, based on TOT and EOT. 

• The availability of aircraft in each period depends on 
previous decisions concerning the time when aircraft 
launch and return. 


Appendix A contains the GAMS source code of the model 
described in this chapter. 
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B. INDICES 


The following indices are used to formulate the 
optimization model: 

a assets 
i sites 
j targets 

m target/mission types 
n strike packages 
t time periods 

An example of the values over which these indices can range 
is: 

as {F-14, F-18, F-15, AV-8B, TLAM} 
is {AIRBASE-01, CV-65, DDG51} 

JS {T-01, T-02, CAP-1, AEW-1, CAS-01} 
me (SAM, HBUNKER, CAP, AEW, CAS} 
ne {PACKAGE-01, PACKAGE-02, PACKAGE-03) 
t e {Tl, T2, T3, T4, T5, T6} 

The j index represents the actual targets and m 
represents the target/mission types. The n index represents 
the various strike packages consisting of assets from index 
a that are have been previously judged appropriate to use 
against the target types of index m. For example, a target 
which is of target type SAM could be assigned one package 
consisting of two A-6's and one EA-6B or a second package 
consisting of two F-15's and one EF-111. The t index 
represents the time, in periods, that an event will occur. 


C. DECISION VARIABLES 

The primary decision variables of the model are binary 
variables. These variables decide which strike package is 
assigned for each target or mission and which site provides 
6 



the assets required in each strike package. The first set 
of binary variables are: 

= 1 if strike package n is assigned to 

target j arriving on top in period t. 

= 0 if not. 

The second set of binary variables are: 

= 1 if site i is authorized to provide asset 

a to target j 

=0 if not. 

There are three other variables in the model. The 
first two are general integer variables: 

= The quantity of asset a allocated from site 
i to strike target j launching in period t 

QL^jj = The quantity of asset a at site i at the end 
of period t. 

Variables Y and Z are both used to provide assets for 
targets or missions from a launch site. They are both 
needed because of the single sourcing constraint. Variable 
QL is needed to keep track of the inventory of assets at 
each launch site. 

The last variable is an elastic variable for target 
non-assignment. It allows the target strike constraint to 
be violated at a cost that is entered as an input parameter. 
The elastic variables are: 

Ej = 1 if target j is left unstruck 

= 0 otherwise. 
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The cost of the elastic variables is prohibitively high, so 
that a target is left unstruck only if it is physically 
impossible to strike all targets at their designated TOT 
with the given assets. The model does not consider the 
possibility of striking at some time other than TOT, because 
of the ripple effect a change might have on subsequent 
sorties. 


D. OBJECTIVE FUNCTION 

The objective function of the model seeks to maximize 
the weighted sum of the selected targets to be struck and 
missions filled less a penalty for non-assignment. A small 
distance penalty is also included in the objective function 
to insure that the closest assets are used whenever multiple 
assets are available. The model assigns the most preferred 
strike package to each target and mission requested by 
comparing the commander's preferences with the capabilities 
of the assets and the requirement to meet the time on target 
(TOT); 

MAXIMIZE 2 EPREFjnXjnt - S TPREFjEPENjEj - 2 DPENaij Yaij 


where: EPREFj„ 

TPREF^. 
EPENj 

DPEN^_..j 


Preference value of the strike package 
Target preference value 
Elastic penalty for not striking the 
target 

Penalty value for distance an asset 
must fly to reach a target. 




EPREF and TPREF are parameters relating the preference 
values which the user inputs during data entry. Chapter III 
discusses these inputs. These parameters ensure that the 
model selects the "best" strike package and highest priority 
targets and missions. DEPN is a distance penalty that is 
computed using the range to the target and the combat radius 
of the aircraft chosen to strike said target. 

E. CONSTRAINT EQUATIONS 

1. Target Strike Constraints 

The first set of constraints ensures that each 
target is struck at its assigned time on target or a penalty 
is assigned. The strike constraints are:. 

E E Xjr:t + Ej = 1 , Vj. 

n t: t=P03’3 

Because X is a binary variable, this constraint ensures that 
either one strike package is assigned at the required time 
oh target or a penalty is assessed. 

2. Demand Constraints 

The second set of constraints ensures that the 
demand for assets at each target at its assigned time on 
target is met. The demands constraints are: 

= ZQTYa,J,nXj,„,t , Va,j,t 

9 




where: = The quantity of asset a in strike 

package n proposed for target j. 

The variable Z uses time index t-FOT^.^ 

where: = the time required for asset a launching 

from site i to fly to target j, 
measured in periods. 

The time index on Z must be adjusted because the time index 
on the X variable refers to the TOT period. 

The left-hand-side of the constraint represents the 
quantity of an asset allocated from a launch site launching 
such that it will make its required time on target. The 
right-hand-side computes the demand for the asset as 
required by the chosen strike package. 

3. Single Sourcing Constraints 

The single sourcing constraints ensures that all 
aircraft for a given strike package against a given target 
come from the same launch site. They are not affected by 
the time index. The single sourcing constraints are: 

SXaij S 1 r Va;t tanker, Vj. 

An exception to the single source requirement is allowed for 
the tanker aircraft, because these missions do not require 
extensive pre-mission briefings and tanker assets from any 
site can perform the mission. 


10 



4. Supply Constraints 


In the original model, the supply constraints were: 
'ZZaij ^ AVAILia , Vi, a 

where: AVAILj, = Quantity of assets of type a available 

at launch site i. 

The parameter AVAILj^ was provided by the game players and as 
assets were used by the various strike packages this 
parameter ensured that assets were not tasked beyond their 
availability. 

The enhanced model replaces the AVAIL^^ parameter by 
the general integer variable QLaif The constraint can now 
be viewed as a traditional inventory balance constraint. 
The supply constraints are: 

'ZZa,i.j,t + QLa,i,t = QLa.i,t-l + % Za, i. j, , Va,i,t. 

The left-hand-side of the constraint represents the assets 
that launch in period t from site i plus the assets that 
remain at the end of period t. The right-hand-side 
represents the assets remaining at the end of the previous 
period plus those aircraft returning in period t from 




The Z variable on the right-hand-side uses time 
index t-CT^^. 

where: = The total time required to fly 

to the target or mission area, 
perform on-station duties, and 
fly back to site i, in periods. 

The supply constraints assume that there is no loss 
of aircraft due to battle damage or mechanical malfunctions. 
It would be mathematically simple to include a deterministic 
aircraft attrition factor in the model, but it would then 
become extremely difficult to obtain integer solutions. The 
more realistic approach of stochastic losses is beyond the 
scope of this thesis. 

5. Logical Constraints 

The logical constraints are needed to ensure that 
the Z variables governing the allocation of assets are 
logically connected to the Y variables which govern the 
single sourcing. The logical constraints are : 

Zaijts AVAJXaiYaij , V a,i,j,t. 

These constraints guarantee that the Y's and Z's are nonzero 
for the same values of a, i, j. 
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PENALTIES 


F. 

1. Elastic Penalty 

The elastic penalty is assessed only if a target or 
mission is not assigned a strike package. The penalty is 
multiplied by the relative importance of the mission or 
target. The goal of the model is to strike all targets and 
meet all mission requirements. The EPEN value is large 
enough that there is no situation where the objective 
function can benefit by deliberately neglecting a target or 


2. Distance Penalty 

As the distance the assigned aircraft must fly 
increases, the distance penalty, DPEN, increases. Initially 
the penalty increases at a gradual rate, until it surpasses 
the aircraft's combat radius, entered as a parameter, 
RANGEj. Beyond RANGE,,, the distance penalty increases more 
rapidly, reflecting the need for in-flight refueling and 
other factors such as crew fatigue and the greater 
possibility of aircraft malfunctions as flight time 
increases. 

The distance penalty is computed as follows; 
f DISTa \ 

DPEN.sj = if DISTij < RANGE, 

where : ml = proportionality constant of DPEN 

when refueling not required 
DISTjj = Distance from site i to target j 
RANGE, = Range of asset a. 

13 





When refueling 
as follows: 

DPEN^. 

where : m2 


is required the distance penalty is computed 


= 1 , if RANGE. . BIST,, 

V RANGE. J •' 

proportionality constant of DPEN after 
refueling. 
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III. DATA REQUIREMENTS 


The optimization program presented here requires a 
significant amount of data concerning the targets, launch 
sites and assets to be entered by the user. For wargames, 
much of the data is available in the game books. However 
some of the data requirements call on the user's general 
military background and familiarization with assets and 
tactics. Data available in the game books include: 

• Target name 

• Target latitude and longitude 

• Target description 

• Launch site name 

• Launch site latitude and longitude 

• Number and type of assets at launch site 

• Asset range and speed 

• Aircraft in-flight refueling capability 

• Aircraft missions and weapons loadouts 
-• Amount of fuel a tanker has to give 

Data not in the game books but required for the model 

are: 

• Target identifier 

• Target/mission type 

15 
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• Targets to be struck 

• Target preference 

• Required time on target 

• Launch site asset availability 

• Amount of fuel taken per in-flight refueling 

• Number of in-flight refuelings per mission 

• Type and number of assets for each target type 

This information is stored in databases and used to 
construct the GAMS input file. The databases and data entry 
is discussed in Chapter IV. The following sections further 
discuss the data requirements outlined above. 

A. TARGET DATA 

1. Target Identifier 

The target identifier should reflect the geographic 
location of a particular target or give a description of the 
mission associated with it. For example, one enemy region 
may have the code name BRONX. Any target which is within 
the BRONX region is given an identifier B-#. A Combat Air 
Patrol mission is given the identifier CAP-#. Using this 
methodology all targets and missions have unique 

identifiers and the user can rapidly identify where a 
particular target is located or what the type of mission is. 
This identifier is used in the formulation of the model as 
the index j . 
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2. Target Latitude and Longitude 


Target latitude and longitude is required to 
determine the distance from a potential launch site to the 
target. The model uses great circles to calculate distance. 

3. Target/Mission Type 

Determining the target/mission type for each target 
or mission is essential. The target descriptions found in 
the game book can help in this task. The user should try to 
limit the number of target/mission types to a manageable 
set. This aids in limiting the number of strike packages 
the user must create. In the real world, each target may be 
unique and require a unique strike package. However the 
limitations of a war game necessitate the grouping of 
targets with similar attributes into the same target/mission 
type. 

The grouping of targets into target types should 
also be based on the user's judgment concerning appropriate 
strike packages. Targets that appear to be very different 
may require the same types of assets to successfully strike 
them, so they can use the same candidate strike packages. 

Missions are also assigned a target/mission type. 
Airborne Early Warning (AEW) and Combat Air Patrol (CAP) are 
examples of missions that could be given types of AEW-1 and 
CAP-2. Missions such as a 2-plane CAP or a 4-plane CAP 
should be given unique types. 
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4. On-Station Time 


Some missions require the assigned aircraft to stay 
airborne for a prescribed duration, called on-station time. 
Missions such as Airborne Early Warning (AEW), tanking and 
Combat Air Patrol (CAP) will have a required on-station 
time. This is a user defined entry. 

5. Target Preference 

When the targets to strike and missions to perform 
have been determined for a given run of the optimization 
model, they must be assigned preferences. Targets that must 
be hit and missions that must be performed receive a 
preference rating of 1. Less critical targets and missions 
receive a rating of 2 to 5 depending on their importance. 

The model converts the preference rating to weights, 
so that the highest priority targets and missions have the 
heaviest weights in the objective function. The function is 
optimized if penalty values are minimized. The model will 
fill all higher weighted tasking, subject to availability, 
before those with a lesser value. If all the targets and 
missions are critical, they can all be given a preference 
rating of 1. This is not advised, however, because if there 
are insufficient assets for all tasking, then the user will 
have no direct influence on the choice of targets to strike 
and the model will select targets on the basis of distance. 


which is possibly a secondary issue in reality. 



LAUNCH SITE DATA 


Index i of the formulation represents the potential 
launch sites of assets within a strike package. 

1. Site Position 

Launch site latitude and longitude is required to 
determine the distance from a potential launch site to the 
target. This distance is used to compute the distance 
penalty for each asset. The model will attempt to select 
launch sites that minimize the distance penalty, assiiming 
the availability requirement is met. 

2. Asset Type and Availability 

The type and nimber of assets at each launch site, 
at the start of a war game, is provided in the game book. 
The number of assets that are available for a given run of 
the optimization model will change as the game progresses. 
Therefore, the number of assets at a launch site is updated, 
as required, before each run of the model. 

C. ASSET INFORMATION 

1. Combat Radius or Range 

This information is provided in the game book under 
Performance Characteristics. The combat radius represents 
the aircraft's unrefueled range. After in-flight refueling, 
the aircraft has its complete range available. 
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2. Speed 

There are several aircraft speeds listed in the game 
book. The speed listed under Performance Characteristics 
represents the tactical speed. It is left to the user's 
discretion as to which speed is used. 

3. Take 

Take refers to the amount of fuel the aircraft will 
take on during an in-flight refueling. This is dependent on 
such factors as distance to target, capacity at the time of 
refueling, and time until recovery. This input parameter, 
represented by TAKE^ in the model, is user defined and 
allows for the computation of a lower bound on the amount of 
gas that will be required for each run of- the model. 

4. Give 

Give refers to the amount of gas the airborne tanker 
aircraft has to give to aircraft requiring in-flight 
refueling. The game book provides this information. This 
input is represented in the model by the parameter GIVE^. 

5. Number of In-Flight Refuelings 

The number of times an aircraft can refuel during 
the course of a mission is limited by the user to account 
for aircrew fatigue and potential aircraft malfunctions as 
flight times increase. A judgment call is made when 
entering this data, which is represented in the model by the 
parameter MAXFILLS^. 
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STRIKE PACKAGES 


D. 

Section A of this chapter presented the concept of 
target/mission types. Each target/mission type is assigned 
from one (1) to three (3) candidate strike packages. Each 
strike package is composed of from one (1) to ten (10) 
different assets, which, as a group, can be considered 
necessary to successfully attack a target or complete a 
mission. 

The strike packages can be a diverse mix of aircraft. 
The number of assets of each type can also vary. The model 
attempts to optimize the ATO by assigning the most preferred 
packages if the assets are available and within reasonable 
ranges. 

Each of the strike packages for a given target type is 
assigned a preference rating. A rating of one (1) is given 
to the most preferred package and subsequent packages are 
rated from two (2) to five (5). If packages are considered 
equal they are given the same preference rating. Assuming 
that the assets in the packages are available, distance 
would then determine which package is preferred. 

The distance penalties discussed in Chapter II have an 
effect on the preference ratings of candidate strike 
packages when used in the objective function. As outlined 
in Dolan, the parameters ml and m2 effect the balance of the 
distance penalty to the strike package preference. The 
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objective function of the model is designed so that a 
package that requires in-flight refueling to complete its 
mission loses one (1) preference rating. Thus, a candidate 
package that has a rating of two (2) and requires in-flight 
refueling is considered equally preferred to a package that 
has a rating of three (3) but does not require in-flight 
refueling. This fact must be considered when selecting the 
preference ratings of the candidate strike packages. 



IV. USER INTERFACE 


The ATO Optimization model requires significant target, 
launch site and asset information. This information was 
originally designed to be stored in any of a number of 
commercially available database or spreadsheet packages. To 
be able to input and effectively retrieve the necessary 
information for each GAMS run required more than a passing 
knowledge of the package chosen. 

The data storage/retrieval program developed in this 
thesis has been designed such that with only a rudimentary 
knowledge of the Windows environment and database type 
programs, the user will be able to create the necessary 
databases needed by the model and also put that data into 
the format required by GAMS. 

Appendix A contains a sample GAMS input file and 
Appendix B contains sample database files created with the 
interface described in this chapter. 

A. GENERAL INTERFACE 

On start-up, the user is informed that the data and 
GAMS files to be created will be written to the A drive and 
that a formatted 3.5 inch floppy disc must be inserted. 
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1. Keyboard/Mouse 

All user interaction may be conducted using either 
the mouse or the keyboard. Keyboard users utilize the TAB 
key to advance through the data fields on each form. 

2. Data Fields 

Each form asks the user to provide data which is 
required by the ATO model. As discussed in the previous 
chapter, most data (number of assets, latitude, longitude, 
etc.) is provided to the user in the game books. The exact 
requirements of each form are discussed below. 

3. Command Buttons 

Command buttons enable the user to add and delete 
records, move forward and backward among the records, search 
for a specific record and exit the database. Databases 
which will be completely revamped for each game, such as the 
Target database have a command button to delete the entire 
database. Command buttons are actuated by either the mouse 
or the keyboard. 

4. List Boxes 

Several forms contain a list box adjacent to a data 
field. These list boxes provide the user with a listing of 
available choices for the field. Except where noted below, 
the user must select a choice offered in the list box. 
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MENUS 


On start-up, the package provides the user with a menu 
selection bar found in many Windows applications. 

1. File 

Under the File menu selection the user choices are 
Make GAMS Input File, Import GAMS Output File, Print or 
Exit. 

a. Make GAMS Input File 

When this option is selected the program executes 
the code to search through the created databases and put the 
data in the format required by GAMS. 

b. Import GAMS Output File 

This option executes the code to import the 
optimized assignment made by the model. 

c. Exit 

This option closes all the database files and 
exits the program. 

2. Databases 

Selecting Databases presents the user with the 
choice of Input/Edit or View. 

a. Input/Edit 

This option allows the user to select any one of 
the six databases supported by the program or have all six 
displayed. These databases are: 
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Period/Time Information 


• Asset Data 

• Launch Site Data 

• Strike Package Data 

• Target Data 

• Hit List Data 

When a database is selected, the associated form is 
displayed. 

b. View 

Selecting this option presents the user with a 
form to view the current data in the Asset, Launch Site, 
Target and Hit List databases. The user may also select 
Packages. This option only presents .the Target/Mission 
Types which have been entered in the Strike Package 
database. The user selects the command button at the bottom 
of the screen for the desired database information. 

c. Print 

This option allows the user to print any or all of 
the following databases: 

• Asset Data 

• Launch Site Data 

• Strike Package Data 

• Target Data 

• Hit List Data 

All of the data contained in these databases is printed. 
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3. Guided Tour 

Selecting Guided Tour presents the user with a 
choice of either Initial Input or Hit List Input. 

a. Initial Input 

This selection displays all the forms for the 
databases which will normally be built prior to the start of 
a game. The following database forms are presented in a 
cascade for the user; 

• Strike Package Data 

• Target Data 

• Launch Site Data 

• Asset Data 

As the user finishes with a database, it can be 
closed and the form removed, reduced to an icon for later 
selection or, by selecting another form, the new selection 
becomes the active form. 

b. Hit List Input 

This selection displays the forms for those 
databases which will be created or most likely modified 
during each round of play. They are: 

• Period/Time Information 

• Strike Package Data 

• Launch Site Data 

• Hit List Data 
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4. Flight Schedules 

Selecting Flight Schedules presents the user with a 
choice of Print by Launch Site (LT), Print by Launch Site 
(TOT), Print by Target, Edit and ATO Information. 

a. Print by Launch Site (LT) 

This selection prints the flight schedule 
suggested by the optimization model sorted by launch site 
and launch time. This format is most useful for data entry 
on the game floor. 

Jb. Print by Launch Site (TOT) 

This selection prints the suggested flight 

schedule sorted by launch site and time on target (TOT). 

c. Print by Target 

This selection prints the suggested flight 

schedule sorted by time on target (TOT). This format is 

most useful for the JFACC cell to evaluate the schedule the 
model has suggested. 

d. Edit 

This selection presents the user with a dialog box 
from which he chooses the file name of the schedule he would 
like to modify. The file names are SKED_LT.TXT, 

SKED_TOT.TXT and SKED_TOT.TXT. Changes made to these files 
do not modify the schedule suggested by the model or have 
any effect on the ATO information file. 
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Print ATO Information 


Selecting Print ATO Information prints the file 
that was created based on the optimization model schedule. 
This file contains the following: 

• A message declaring all targets have been assigned a 
strike package or lists the targets not assigned 

• The end of period inventory at each launch site by 
asset 

• Sortie totals at each launch site by asset 

• Total sorties scheduled 

• An estimate of the amount of fuel required for 
in-flight refueling 

Appendix C contains flight schedules in the format 
mentioned above and the ATO Information printout. 

C. DATABASE FORMS 

As stated previously, only data which is required by the 
ATO Optimization model is solicited from the user. The 
following sections describe each database form, the data 
requested on the form. 

1. Period/Time Information 

This form requests the time information needed by 
the ATO model. The specific data requirement is: 

• Number of periods in a 24 hour day 
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This requirement is a subjective input and the 
user makes his selection from the list provided on the form. 
The ATO model bases all its time calculations on the 
selected number. Figure 1. depicts the time period input 
form. 


# OR 
REFtlODS 


There are A 
hours in each 
period 


□ 


EXIT 


Figure 1. Time Period Input Form 
2. Asset Database 


The Asset database requires the following 
information: 


• Asset name 

.• Combat radius (range) 

• Speed 

• Take 

• Give (tankers only) 

• Number of in-flight refuelings per mission 

The asset name may be selected from the list 
provided or, if not on the list, typed in. Asset combat 
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radius, speed and tanker give are provided in the game 
books. The amount of fuel received during inflight 

refueling and the number of inflight refuelings allowed 
during a mission are subjective inputs from the user as 
discussed in Chapter III. Figure 2 depicts the asset input 
form. 

ASSET 


COMBAT 
RADIUS 

SPEED 

TAKE 

GIVE 

# of IFR 

Figure 2. Asset Input Form 


A-10 

A-6 

AV-8B 

B-1 

E-2 

E-3A 

EA-GB 

EF-111 

F-111 

F-117 

F-U 


ADD 


DaETE 


NEXT 


PfMOUS 


SEARCH 




EXIT 
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3. Launch Site Database 


The Launch Site database contains the information 
needed about all potential asset launch sites. The database 
requires the following information: 

• Launch site name 

• Site latitude and longitude 

• Type of assets available 

• Number of each asset 

All information required for this database is contained, 
initially, in the game books. The number of available 
assets will change throughout the game and will need to be 
updated prior to each GAMS run. The launch site name may be 
modified or abbreviated for ease of use. A single site can 
have up to ten (10) different types of assets operating from 
it. If there are more than ten different assets, a second 
launch site with a unique name but the same latitude and 
longitude can be used. Figure 3 depicts the launch site 
input form. 
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4. Target List Database 

The Target List database contains the information 
needed on all targets. This database requires the following 
information; 

• Target identifier 

• Target name 

• Target latitude and longitude in degrees and minutes 

• Target type 

• On-station time (if needed) 

Target name and latitude and longitude are provided 
in the game book. Target identifier (Target ID) is user 
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defined as discussed in Chapter III. Target type must be 
selected from the list of choices offered in the list box. 
This ensures that there is a strike package associated with 
this target type, otherwise a GAMS error would result. 
Figure 4 depicts the target input form. 


1 . . . 1 

TARGET ID 1 

1_1 

1 Dmjsm 1 

LATITUDE rir~| [2i~~| 

mm 

LONaiTUDE rTTFl |os 1 

'WBEXT ' i 


|PWE«#MUS1 

lisapa Iafl^ 


TARGET TYPE | bldg 

I I 

°TIME^'^'°'^ 

(in minutes) [tanker_ 

I \ 



D^JEWE ALL REt^JRDS j 


Figure 4. Target Input Form 

This form appears when Initial Input is chosen. It 


is assumed that all potential targets are listed in the game 
book (or supplemental information). If new targets become 
available during the course of the game, selecting 
Databases, Target List from the menu allows the user to add 
new targets. 

When the user selects the Search command button on 
the Target List form he is informed that the search is done 
using the target ID vice the target name. 
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5. Strike Package Database 


The Strike Package database requires the following 
information; 

• Target/Mission type 

• Asset name 

• How many of the selected asset to include in the 
package 

• Package preference 

As discussed in Chapter III target/mission type is 
used to categorize each target or mission into a manageable 
number of different classes. Examples of target/mission 
types include AIRFIELDS, SAM SITES, NAVAL BASES, POL 
STORAGE, COMBAT AIR PATROL (CAP), AIRBORNE EARLY WARNING 
(AEW) , and TANKER. The user then builds up to three (3) 
different combinations of assets, called strike packages, 
with which to use against a particular target or for a 
mission. 

For each package the user may select up to ten (10) 
different assets and chooses how many of each asset to 
include. The user then assigns a preference for the 
package, as discussed in Chapter III. The range is from 1 
(highest or most preferred) to 5 (lowest or least 
preferred). Figure 5 depicts the strike package input form. 
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Figure 5. Strike Package Input Form 
6. Hit List Database 

The Hit List database contains information about the 
targets which the user desires to strike for a particular 
iteration of the GAMS program. The Hit List database 
requires the following data: 

• Target ID 

• Target preference 

• Time on target 

36 




The target ID is used to identify the target and 
must be selected from the list provided on the form. The 
list contains all the targets that have been entered in the 
Target database. 

The preference field is used to prioritize the 
targets as outlined in Chapter III. The highest priority 
target should be given a preference value of one (1) and the 
lowest a value of five (5) . Time on target is entered in 
military time, i.e.. 04 hours 00 minutes, 23 hours 15 
minutes. Figure 6 depicts the hit list input form. 



37 
























V. RESULTS 


A sample problem with 37 targets to be struck was run 
on an IBM compatible 486/50 computer with 64 megabytes of 
random access memory (RAM) using GAMS and XA. Eight, 12 and 
24 period models were tested with optimality tolerances of 
.25, .10, .05 and .01. The results of these runs is 
discussed below. 

Properly defining the time index is a critical aspect 
of the model. As discussed in Chapter II, the parameters CT 
(cycle time), EOT (fly out time) and ST (on-station time) 
are used to properly relate the X and Z variables and are 
critical in the demand and inventory constraints. The model 
uses integer values in units equal to the size of a time 
period for CT, with a minimum CT of 1. A cycle time of zero 
would imply that an asset could fly an infinite number of 
sorties in any given period. A non-integer cycle time 
cannot be accounted for within a model that discretizes 
time. FOT's are also assigned integer values greater than 
or equal to zero. ST's are integer values greater than or 
equal to zero. 

A problem can arise when the EOT and ST parameters are 
rounded off to integers, because the model defines CT as 
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CT = (2 * FOT) + ST, with a minimum value of 1. This 
equation must be observed in the input data. Therefore, 
under certain conditions, the fly out time and/or on-station 
time parameters must be modified. Appendix A contains the 
GAMS code that is used to accomplish the required 
transformation of these parameters. These transformations 
ensure the X and Z variables are properly related and that 
the demand and inventory constraints are properly indexed. 

A. MODEL OUTPUT 
1. Run Time 

As discussed above, the model was run varying the 
number of periods and the optimality tolerances. Table 1 
contains the results of these runs. OPTCR is the optimality 
tolerance the user assigns in the GAMS code. When the model 
achieves its first solution that is within the set tolerance 
to the lowest available upper bound, it halts. The upper 
bounds are derived from linear programming relaxations of 
the integer program. The best integer solution column shows 
the value of the objective function of the model when the 
OPTCR is satisfied and an integer solution has been found. 
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TABLE 1. RUN RESULTS 


1 # of 
Periods 

OPTCR=.25 1 OPTCR=.10 ' 

Run LP Best Int Run LP Best Int 

Time Bound Solution Time Bound Solution 

1 

8 

0:00:24 

178.1 

146.5 

0:45:13 i 

164.9 

149.9 

12 

0:00:11 

178.3 

149.9 

1:03:25 

161.1 

146.5 

24 

0:00:15 

178.1 

147.8 

1:44:26 

160.1 

145.5 j 


OPTCR = .05 

Run LP Best Int 

Time Bound Solution 

OPTCR=01 

Run LP Best Int 

Time Bound Solution 

8 

0:24:23 

1 

162.8 

155.0 

> 10 hrs 



12 

0:58:37 

161.6 

1 153.9 

>10hrs 



24 

1:07:17 

160.8 

1 153.1 

> 10 hrs 




As Table 1 clearly demonstrates, increasing the 
number of periods and/or decreasing the optimality tolerance 
increases the run time of the model. All runs to within 1 
percent of optimality were still running at the 10 hour mark 
and these runs were then terminated prior to completion due 
to the excessive run time. At termination, the model's best 
integer solution was the same as the 5 percent solution. 

2. Model Assignment 

As the optimality tolerance gets farther away from 
zero, the model has more flexibility in assignment and may 
select a suboptimal strike package for a particular mission, 
but only to the degree that the overall objective function 
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satisfies the tolerance. This means that a target may be 
assigned a strike package which is not the most preferred. 
An example will help to illustrate this point. 

When the 8 period model is solved to within 25 and 
10 percent optimality there are seven targets, T-04, T-12, 
T-15, T-22, T-22, T-24, T-26 and T-27 that are assigned 
strike packages which are not the most preferred. When the 
same model is solved to within 5 percent optimality only 
targets T-12 and T-24 are assigned lesser preferred 
packages. The tradeoff in better assignment of strike 
packages comes at the expense of run time, i.e., a 25 
percent optimal solution run time is 24 seconds and a 5 
percent optimal solution run time is 24 minutes and 23 
seconds. 

3. Effect of Number of Periods 

As discussed above, as the number of periods in the 
model increases, the run time increases. This result was 
anticipated because as the number of periods the model uses 
increases the number of sorties an asset can potentially fly 
also increases. This is due to the fact that as the number 
of hours in a period decreases, assets are ready for 
assignment sooner. Therefore, the model has more potential 
combinations of assignments to examine, thus increasing run 
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4. Flight Schedules 

The output of the GAMS model is imported into the 
Windows interface and the assignments from the model are 
then written as flight schedules for use by either the 
JFACC cell or the game floor. The schedule for the JFACC 
cell lists the targets, launch site, assets assigned, the 
number of assets and the TOT. The schedule for the game 
floor presents the above information along with the launch 
time required and the target latitude and longitude. This 
facilitates rapid data entry on the floor. 

5. ATO Information 

The model also provides a file which includes 
information on the number of sorties flown from each launch 
site by asset, an approximation of the amount of fuel that 
will be required to fly the schedule, and an end-of-period 
inventory for each asset. Appendix C contains the flight 
schedules and ATO information printout for the 8 period run. 
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VI. CONCLUSIONS 


The enhanced Air Tasking Order Optimization Model and 
user interface developed for this thesis rectifies the 
shortcomings that were encountered with the model's initial 
use at the Naval War College. First, the user can now 
successfully model a multiple period day, allowing assets to 
be used several times a day as they are in the real world. 
Second, it provides the user with a graphical user interface 
which is easy to manipulate for data entry, constructing the 
GAMS file needed by the optimization model and producing 
output that assists the players both in the JFACC cell and 
the game floor. This interface eliminates the need for the 
user to be more than passingly familiar with GAMS or skilled 
at the use of a commercial database program. 

Originally, the optimization model was developed to 
help allow the JFACC cell of a wargame to rapidly produce a 
flyable ATO and not slow the pace of the wargame because of 
the time consuming process producing such an ATO may entail. 
The enhanced model successfully produces a flyable ATO in 
much less time than the manual method and with an efficient 
use of assets. Additionally, the enhanced model presents 
the user with an end-of-period inventory which can aid in 
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reassigning assets if the JFACC deems changes to the 
suggested schedule are necessary. 


A. RECOMMENDATIONS 

The results presented in Chapter V suggest several 
recommendations in the implementation of the model. First, 
using an 8 or 12 period day should provide sufficient 
numbers of sorties per aircraft to fly most ATOs. Using a 
24 period day may cause an unacceptable run time due to the 
size of the model or the optimality tolerance being used. 
Additionally, 2 or 3 hours per period can mask the affects 
of real world variation in fly out time, on-station time and 
rearm and refuel time without affecting the feasibility of 
the solution. Second, modifying the optimality tolerance to 
a value closer to zero, while potentially producing a 
"better" ATO, significantly increases run time. As the size 
of the model and number of periods increases, the model will 
take longer to solve. A "first cut" using .25 OPTCR should 
provide the user with a good ATO rapidly. If time allows, 
decreasing OPTCR to .05 and rerunning the model may produce 
a better ATO. 

B. REFINEMENTS 

The current model allows multiple sorties in a day but 
is restricted to a single sortie per period. If the period 
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length is long in comparison to sortie length, this 
restricts the use of assets. Further work can be done to 
allow multiple sorties in a given period. 

Time required for in-flight refueling and to refuel and 
rearm aircraft after landing are presently not incorporated 
in the calculations of mission time. Incorporating these 
would add further fidelity to total mission time. 

C. FUTURE PROJECTS 

There are several potential projects that can be pursued 
with this model. First would be a program that uses the 
weapons versus target data found in the Joint Munitions 
Effectiveness Manual (JMEM) and the weapons loadouts given 
in the gamebooks to determine and rank the best combination 
of assets to use against a particular target type. This 
would reduce the work required to create the packages and be 
of tremendous help to players who are not tactically 
proficient. 

A second project would be determining the optimal 
placement of tanker assets to meet the ATO that the 
optimization model produces. 
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APPENDIX A. GAMS CODE AND DATAFILE 


This appendix contains the GAMS source code and the 
sample datafile for an 8 period ATO required by the enhanced 
ATO Optimization Model. 

$TITLE Naval Postgraduate School 

$ENHANCED AIR TASKING ORDER OPTIMIZATION MODEL 

$STITLE ATOFIXl (ver. 94/07/10) 

$offupper offsymxref offsymlist offuellist inlinecom { } 
$ontext 

25 AUG 94 K CRAWFORD 

$offtext 
options 

limrow = 

limcol = 

solprint = 

mip = 

rmip = 

optcr = 


iterlim = 
reslim = 


SETS 

A assets 
I sites 
J targets 
N strike packages 

M mission types 

TYPE target type 
K coordinates 

T time 

POT period on top 


0.25 {«< optimality tolerance: values 

closer to zero may give better 
solutions but will take longer} 

5000000 

150000 {maximum solve time in seconds} 


$INCLUDE A:\ATO.DAT 
$INCLUDE ATO.DIS 
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PARAMETERS 

QTY(a,j,n) quantity of asset a in strike package n on 
target j 

EPREF(j,n) effectiveness-based preference of strike package 
USED(a,j) checks if asset is potentially used against 
target 

DPEN(a,i,j) Penalty for travel distance 

JMAP(j,iti) Mapping parameter 

TPREF(j) Target Preference of target j 

ST(j) On station time required at target j 

OST(a,i,j) On station time req. of asset a launching from i 
striking j{ new parameter required to make ST(j) 
compatable with CT(a,i,j)) 

CT(a,i,j) Total mission time in periods 
{includes on station time} 

FOT(a,i,j) Fly out time in periods ; 

QTY(a,j,n) = SUM(m $TYPE(j,m),STRIKEDATA(m,n,a,"QUANTITY")); 

EPREF{j,n) = SUM(m $ TYPE(j,m), SMAX( a, 

STRIKEDATA(m,n,a,"PREFERENCE"))); 

USED (a,j) = SUM(m $ TYPE(j,m), SUM( n , 

STRIKEDATA{m,n,a,"QUANTITY")) ); 

DPEN(a,i,j)$(AVAIL(i,a) andUSED(a,j) and(DIST(i,j) LE 
RANGE (a))) = ml*((DIST(i,j)/RANGE(a)) ); 

DPEN(a,i,j)$(AVAIL(i,a) andUSED(a,j) and(DIST(i,j) GE 
RANGE(a))) = ceil ((DIST(i,j)-RANGE(a))/ 

RANGE(a)) + m2*((DIST(i,j)-RANGE(a))/RANGE(a)); 

CT(a,i,j)$(AVAIL(i,a) and USED(a,j)) 

= ceil((((2*DIST(i,j))/SPEED(a))+(ST(j)/60))/ph) ; 

FOT(a,i,j)$(AVAIL(i,a) and USED(a,j)) 

= round((DIST(i,j)/SPEED(a))/ph); 

ST(j) = round( (ST(j)/60)/ph ); 

* Check CT-ST. If odd then ST = ST + 1 and FOT = (CT-ST)/2 
*.define OST for a,i,j, combinations 

OST(a,i,j) $((CT(a,i,j)$(AVAIL(i,a) and USED(a,j)))) =ST(j); 

OST(a,i,j) $( (CT(a,i,j)$(AVAIL(i,a) and USED(a,j))) and 

( mod( CT(a,i,j) - st(j) , 2) eq 1 )) = st(j)+l ; 

* redefine FOT 

FOT (a,i,j)$((CT(a,i,j)${AVAIL(i,a) and USED(a,j))) and 
( mod( CT(a,i,j) - st(j) , 2) eq 1 )) 

= (CT(a,i,j) - OST(a,i,j))/2; 
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BINARY VARIABLES 

X(j,n,t) Strike package n assigned to target j arriving 
on top in t 

Y(a,i,j) Site i authorized to provide asset a to target j 


POSITIVE VARIABLES 

E(j) Elastic variable for not striking target 

Z(a,i,j,t) Quantity of asset a allocated from site i to 
target j launching in period t 
QL(a,i,t) Quantity of asset a at site i at the end of 
period t ; 

FREE VARIABLE 

OBJ Objective variable 


EQUATIONS 

STRIKE(j) Strike each target with exactly one package 

DEMAND(a,j,t) Meet demand for assets at each target 
SINGLE(a,j) Use single site as source of each asset for 

each target 

SUPPLY (a,i,t) Observe asset availability at sites 
LOGICAL(a,i,j,t) Variable upper bound relating Y and Z 
OBJDEF 


STRIKE(j).. 

SUM((n,t) $ EPREF(j,n) , 

X(j,n,t) $ POT(j,t) ) + E(j) =E= 1 ; 


DEMAND(a,j,t) $ (USED(a,j)$POT{j , t) ) 


SUM(i $(AVAIL(i,a) and (Dist(i,j) LE MAXFILLS(a)* 
RANGE(a))), Z(a,i,j,t-FOT(a,i,j))) 


SUM(n,QTY(a,j,n) * X(j 


t) ) 



{A single launch site is used for all aircraft types. The 
only exception are tankers. Tankers may come from any 
launch source} 

SINGLE(a,j) $( USED(a,j)and (GIVE(a) eq 0)) .. 

SUM(i $ (AVAIL(i,a) and (Dist(i,j) LE 
MAXFILLS(a)*RANGE(a))) , Y(a,i,j) ) 

=L= 1 ; 

SUPPLY(a,i,t) $ AVAIL(i,a) .. 

SUM(j $(USED(a,j) and (Dist(i,j) LE MAXFILLS(a)*RANGE(a)))- 
Z(a,i,j,t) $ POT(j,t+FOT(a,i,j))) + QL(a,i,t) 


QL(a,i,t-l) + 

SUM (j $ (POT(j,t-(OST(a,i,j)+ FOT(a,i,j)})), 

Z(a,i,j,t-CT(a,i,j))) + 

AVAIL(i,a)$(ORD(t) eq 1); 

LOGICAL(a,i,j,t) $ ( ( (AVAIL(i,a) ANDUSED(a,j) and 

(Dist(i,j) LE MAXFILLS(a)*RANGE(a)) )) 

$ POT(j,t+FOT(a,i,j))).. 

Z(a,i,j,t) 

=L= 

AVAIL(i,a) * Y(a,i,j) ; 


OBJDEF.. 
XSCALE * 

- ESCALE 

- DSCALE 

=E= OBJ 


SUM( (j,n,t) $POT(j,t), EPREF(j,n) *X(j,n,t) 

* SUM( j, TPREF(j)*EPEN(j} * E(j) ) 

* SUM((a,i,j) $(AVAIL(i,a) ANDUSED(a,j) 

and (Dist(i,j) LE MAXFILLS(a)*RANGE(a)) 
DPEN(a,i,j) * Y(a,i,j) ) 
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MODEL ATO /ALL/ ; 

SOLVE ATO USING MIP MAXIMIZING OBJ ; 

FILE FI /A: WBIN.OUT/; 

FILE F2 /A:\ato.out/; 

PUT FI ; 

LOOP((j,a,i,t) $ Z(a,i,j,t), 

put j.TL:1I,", ", i.TL:ll,",", z.L(a,i,j,t) :3:0,",", 
a.TL:ll,",", TIME(j):4:0,DIST(i,j)/; 


Put F2; 

if ( sum(j,e.L(j)) gt 0.01, 

put " THE FOLLOWING TARGETS WERE NOT ASSIGNED"/ 
put " "/ 

LOOP(j $ E.L(j), 

put j.TL:11/; 
put ""/; 

) ; 

else 

put " ALL TARGETS WERE ASSIGNED" / ) ; 

put/; 
put / ; 

PUT F2; 

PUT " 

PUT " 

loop(t, put 
put /; 

loop(i, 

put i.TL:15/; 
loop(a$AVAIL(i,a) , 

put a.TL @16:11 


END OF PERIOD INVENTORY", 


loop(t, 

put QL.L(a,i,t):5:0; 


put/; ); 

put/; ); 

DISPLAY DIST 

DISPLAY CT, FOT, OST; 

DISPLAY X.L, Z.L, QL.L ; 
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T-17 

T-18 

T-19 

T-20 

T-21 

T-22 

T-24 

T-25 

T-26 

T-27 

T-28 

T-29 

T-30 

T-31 

T-32 

T-33 

T-34 

/ 

M mission type(target type) 

SAM 

AFL 

AFS 

BLDG 

HBUNK 

AEW 

TANKER 

CAP-IA 

CAP-IB 

CAP-1C 

ROAD-BRDG 

TLAM 

POL 

EW-NITE 

CAS 

/ 

Type (J,M) 

/ 

T-02 .BLDG 

T-04 .HBUNK 

T-06 .AFL 

T-07 .AFL 

T-08 .SAM 

T-09 .AFS 

EYE-1 .AEW 

C-1 .CAP-IA 

C-2 .CAP-IA 

C-3 .CAP-IA 

TEXACO-A .TANKER 

T-01 .AFL 

T-03 .AFS 

T-10 .BLDG 

T-11 .HBUNK 

T-12 .POL 
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1 


T-13 .ROAD-BRDG 

T-15 .POL 

T-16 .BLDG 

T-14 .TLAM 

T-17 .EW-NITE 

T-18 .ROAD-BRDG 

T-19 .AFS 

T-20 .BLDG 

T-21 .EW-NITE 

T-22 .POL 

T-24 .POL 

T-25 .HBUNK 

T-26 .ROAD-BRDG 

T-27 .ROAD-BRDG 

T-28 .TLAM 

T-29 .SAM 

T-30 .EW-NITE 

T-31 .CAS 

T-32 .CAS 

T-33 .CAS 

T-34 .CAS 

/ 

T time periods 

/ T1*T8 / 

N strike packages 

/ PACKAGE-1*PACKAGE-3 / 

POT (j,t) time period assigned to target 

/ 

T-02 . T3 

T-04 . T4 

T-06 . T6 

T-07 . T4 

T-08 . T7 

T-09 . T5 

EYE-1 . T3 

C-1 . T3 

C-2 . T3 

C - 3 . T4 

TEXACO-A . T3 

T-01 . T3 

T-03 . T3 

T-10 . T4 

T-11 . T6 

T-12 . T6 

T-13 . T4 

T-15 . T5 

T-16 . T3 

T-14 . T4 

T-17 . T8 

T-18 . T6 

T-19 . T6 

T-20 . T5 

T-21 . T8 

T-22 . T4 
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T-24 . T4 

T-25 . T5 

T-26 . T7 

T-27 . T5 

T-28 . T2 

T-29 . T7 

T-30 . T1 

T-31 . T1 

T-32 . T2 

T-33 . T3 

Tt34 . T4 

/ ; 

TABLE STRIKEDATA(m,n,a,*) 


PREFERENCE 

QUANTITY 

SAM 

Package-l 

F-18 

2 

2 

SAM 

Package-2 

F-15 

2 

3 

SAM 

Package-3 

A-6 

2 

5 

SAM 

Package-3 

EA-6B 

1 


AFL 

Package-1 

A-6 

4 

5 

AFL 

Package-l 

F-14 

4 


AFL 

Package-2 

F-18 

4 

3 

AFL 

Package-3 

F-15 

4 

4 

AFS 

Package-1 

A-6 

2 

5 

AFS 

Package-2 

F-15 

2 

3 

AFS 

Package-3 

F-14 

2 

2 

BLDG 

Package-1 

A-6 

2 

4 

BLDG 

Package-2 

F-111 

2 

5 

BLDG 

Package-3 

F-18 

2 

3 

HBUNK 

Package-1 

A-6 

4 

5 

HBUNK 

Package-1 

F-14 

2 


HBUNK 

Package-2 

F-15 

4 

5 

HBUNK 

Package-3 

F-18 

4 

4 

AEW 

Package-1 

E-3A 

1 

5 

TANKER 

Package-1 

KC-10 

1 

5 

CAP -lA 

Package-1 

F-14 

2 

5 

CAP -IB 

Package-1 

F-14 

2 

5 

CAP-IB 

Package-2 

F-18 

2 

4 

ROAD-BRDG 

Package-1 

F-18 

2 

5 

ROAD-BRDG 

Package-2 

F-14 

2 

4 

ROAD-BRDG 

Package-3 

F-15 

2 

5 

TLAM 

Package-1 

THAWK 

2 

5 

POL 

Package-1 

A-6 

2 

5 

POL 

Package-2 

F-15 

2 

4 

EW-NITE 

Package-1 

F-117 

1 

5 

EW-NITE 

Package-2 

A-6 

2 

4 

CAS 

Package-1 

A-10 


5 

CAS . Package-2 

Parameter Time (J) time 

/ 

T-02 0800 

T-04 1045 

T-06 1530 

F-18 

; on top 
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T-07 1030 
T-08 2030 
T-09 1425 
EYE-1 0630 
C-1 0700 
C-2 0900 
C-3 1100 
TEXACO-A 0630 
T-01 0720 
T-03 0800 
T-10 0920 
T-11 1615 
T-12 1715 
T-13 1045 
T-15 1220 
T-16 0829 
T-14 1130 
T-17 2215 
T-18 1600 
T-19 1530 
T-20 1340 
T-21 2245 
T-22 0940 
T-24 1130 
T-25 1440 
T-26 1920 
T-27 1215 
T-28 0500 
T-29 1805 
T-30 0230 
T-31 0300 
T-32 0500 
T-33 0800 
T-34 1000 
/ ; 

Parameter TPREF (J) 

/ 

T-02 1 
T-04 3 
T-06 2 
T-07 1 
T-08 2 
T-09 1 
EYE-1 1 
C-1 1 
C-2 1 
C-3 1 
TEXACO-A 1 
T-01 2 
T-03 1 
T-10 2 
T-11 3 
T-12 1 
Tt13 2 
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T-15 1 

T-16 2 

T-14 1 

T-17 2 

T-18 1 

T-19 2 

T-20 3 

T-21 2 

T-22 1 

T-24 1 

T-25 2 

T-26 3 

T-27 1 

T-28 2 

T-29 1 

T-30 2 

T-31 1 

T-32 1 

T^33 1 

T-34 1 

/ ; 

Parameter RANGE 

/ 

A-10 
A-6 
B-1 
F-117 
F-14 
F-15 
F-18 
KC-10 
E-2 
E-3A 
F-111 
EA-6B 
THAWK 
/ ; 

Parameter SPEED 

/ 

A-10 
A-6 
B-1 
F-117 
F-14 
F-15 
F-18 
KC-10 
E-2 
E-3A 
F-111 
EA-6B 
THAWK 
/ ; 


(a) 

500 

600 

1500 

600 

600 

650 

450 

2000 

800 

1000 

650 

500 

1000 

(a) 

300 

450 

1000 

550 

600 

600 

500 

300 

300 

300 

500 

500 

300 
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Parameter FILL (a) 

/ 

A-10 2 

A-6 2 

B-1 2 

F-117 2 

F-14 2 

F-15 2 

F-18 2 

F-111 2 

EA-6B 2 

/ ; 

PARAMETER GIVE (a) 

/ 

A-10 0 

A-6 0 

B-1 0 

F-117 0 

F-14 0 

Ft15 0 

F-18 0 

KC-10 0 

E-2 0 

E-3A 0 

F-111 0 

EA- 6B 0 

THAWK 0 

/ ; 

PARAMETER MAXFILLS (a) 

/ 

A-10 1 

A-6 3 

B-1 2 

F-117 3 

F-14 ' 3 

F-15 3 

F-18 3 

KC-10 1 

E-2 1 

E-3A 1 

F-111 3 

EA-6B 3 

THAWK 1 

/ ; 

TABLE LOC(i,*) 

LAT-DE 

cv-es 30 

Airbase-01 32 

Airbase-02 33 

AIRBASE-03 32 

AIRBASE-04 35 

MAG-01 35 

SSN-69 30 


LAT-MIN LONG-DEG LONG-MIN 


30 110 30 

38 119 36 

46 110 46 

06 115 34 

00 95 43 

05 110 48 

35 110 30 
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TABLE COORD(j,* 

LAT-DEG 

LAT-MIN 

LONG-DEG 

LONG-MIN 

T-02 

43 

03 

115 

30 

T-04 

41 

00 

101 

32 

T-06 

39 

06 

104 

17 

T-07 

40 

46 

107 

16 

T-08 

44 

44 

114 

44 

T-09 

38 

38 

115 

55 

EYE-1 

31 

31 

109 

29 

C-1 

33 

33 

110 

00 

C-2 

33 

33 

110 

00 

C-3 

33 

33 

110 

00 

TEXACO-A 

32 

06 

102 

33 

T-01 

40 

29 

117 

05 

T-03 

42 

04 

97 

31 

T-10 

40 

32 

117 

15 

T-11 

41 

00 

116 

45 

T-12 

40 

44 

117 

31 

T-13 

39 

25 

117 

03 

T-15 

40 

12 

115 

45 

T-16 

41 

00 

116 

43 

T-14 

39 

55 

116 

32 

T-17 

40 

21 

116 

45 

T-18 

39 

52 

116 

54 

T-19 

39 

35 

116 

41 

T-20 

39 

17 

111 

32 

T-21 

38 

45 

116 

45 

T-22 

40 

25 

116 

45 

T-24 

41 

00 

116 

24 

T-25 

39 

56 

111 

34 

T-26 

39 

24 

116 

45 

T-27 

39 

12 

116 

30 

T-28 

40 

13 

116 

29 

T-29 

40 

12 

115 

56 

T-30 

41 

00 

117 

00 

T-31 

37 

00 

110 

00 

T^32 

37 

05 

117 

15 

T-33 

37 

00 

109 

45 

T-34 

37 

03 

110 

10 

PARAMETER AVAIL 

(i,a) 




/ 

CV-65 

. A-6 


12 


CV-65 

. F-18 


20 


CV-65 

. F-14 


12 


CV-65 

. E-2 


3 


CV-65 

. EA-6B 


4 


Airbase-01 

. F-117 


10 


Airbase-02 

. F-15 


20 


Airbase-02 

. F-111 


10 


AIRBASE-03 

. KC-10 


6 


AIRBASE-04 

. E-3A 


4 


MAG-01 

. F-18 
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MAG-01 . A-10 12 

SSN-69 . THAWK 12 

/ ; 

PARAMETER ST (j) 

/ 

EYE-1 360 

C-1 120 

C-2 120 

C-3 120 

TEXACO-A 480 

T-31 30 

T-32 30 

T-33 30 

T-34 30 

/ ; 

PARAMETER EPEN(J) elastic penalty for not striking target j; 
EPEN(J) = 100 ; 

PARAMETER XSCALE Objective function scale factor for 
strike preference ; 

XSCALE = 1 ; 

PARAMETER ESCALE Objective function scale factor for 
elastic penalties ; 

ESCALE = 1 ; 

PARAMETER DSCALE Objective function scale factor for strike 
distance ; 

DSCALE = 1 ; 

SCALARS 

ml short range slope /.5/ 

ni2 long range slope /. 7/ 

ph / 3 / ; 
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APPENDIX B. SAMPLE DATAFILES 



This appendix contains printouts of the sa 

mple datafi 

les 

created by 

the inter 

face designed 

for this the 

sis. 




ASSET DATABASE 



NAME 

COMBAT 

SPEED 

TAKE 

GIVE 

# 


RADIUS 




IFR 

A-10 

500 

300 

2,000 

0 

0 

A-6 

600 

450 

2,000 

0 

3 

B-1 

1, 500 

1, 000 

2, 000 

0 

2 

Fr-117 

600 

550 

2,000 

0 

3 

F-14 

600 

600 

2, 000 

0 

3 

F-15 

650 

600 

2, 000 

0 

3 

F-18 

450 

500 

2, 000 

0 

3 

KC-10 

2,000 

300 


00,000 

0 

E-2 

800 

300 


0 

0 

E-3A 

1, 000 

300 


0 

0 

F-111 

650 

500 

2,000 

0 

3 

EA-6B 

500 

500 

2,000 

0 

3 

THAWK 

1, 000 

300 


0 

0 


HITLIST DATABASE 




TARGET ID 


TOT 

PREFERENCE 



T-02 


0800 

1 



T-04 


1045 

3 



T-06 


1530 

2 



T-07 


1030 

1 



T-08 


2030 

2 



T-09 


1425 

1 



EYE-1 


0630 

1 



C-1 


0700 

1 



C-2 


0900 

1 



C-3 


1100 

1 



TEXACO-A 


0630 

1 
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PREFERENCE 


TARGET ID 
T-01 0720 2 

T-03 0800 1 

T-10 0920 2 

T-11 1615 3 

T-12 1715 1 

T-13 1045 2 

T-15 1220 1 

T-16 0829 2 

T-14 1130 1 

T-17 2215 2 

T-18 1600 1 

T-19 1530 2 

T-20 1340 3 

T-21 2245 2 

T-22 0940 1 

T-24 1130 1 

T-25 1440 2 

T-26 1920 3 

T-27 1215 1 

T-28 0500 2 

T-29 1805 1 

T-30 0230 2 

T-31 0300 1 

T-32 0500 1 

T-33 0800 1 

T^34 1000 1 

LAUNCH SITE DATABASE 

SITE NAME LATITUDE LONGITUDE ASSETS # 

CV-65 30 30 110 30 A-6 12 

F-18 20 

F-14 12 

E-2 3 

EA-6B 4 

Airbase-01 32 38 119 36 F-117 10 

Airbase-02 33 46 110 46 F-15 20 

F-111 10 

AIRBASE-03 32 06 115 34 KC-10 6 

AIRBASE-04 35 00 095 43 E-3A 4 

MAG-01 35 05 110 48 F-18 12 

A-10 12 


SSN-69 


30 35 


110 30 
61 
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STRIKE 

PACKAGES DATABASE 


TARGET TYPE 

PACKAGE # 

ASSET 

QUANTITY 

PREF 

SAM 

Package-1 

F-18 

2 

2 


Package-2 

F-15 

2 

3 


Package-3 

A-6 
EA-6B 

2 

1 

5 

AFL 

Package-1 

A-6 
F-14 

4 

4 

5 


Package-2 

F-18 

4 

3 


Package-3 

F-15 

4 

4 

AFS 

Package-1 

A-6 

2 

5 


Package-2 

F-15 

2 

3 


Package-3 

F-14 

2 


BLDG 

Package-1 

A-6 

2 

4 


Package-2 

F-111 

2 

5 


Package-3 

F-18 

2 

3 

HBUNK 

Package-1 

A-6 

4 

5 



F-14 

2 



Package-2 

F-15 

4 

5 


Package-3 

F-18 

4 

4 

AEW 

Package-1 

E-3A 

1 

5 

TANKER 

Package-1 

KC-10 

1 

5 

CAP-IA 

Package-1 

F-14 

2 

5 

CAP-IB 

Package-1 

F-14 

2 

5 


Package-2 

F-18 

2 

4 

ROAD-BRDG 

Package-1 

F-18 

2 

5 


Package-2 

F-14 

2 

4 


Package-3 

F-15 

2 

5 

TLAM 

Package-1 

THAWK 

2 

5 

POL 

Package-1 

A-6 

2 

5 


Package-2 

F-15 

2 

4 

EW-NITE 

Package-1 

F-117 

1 

5 


Package-2 

A-6 

2 

4 

CAS 

Package-1 

A-10 

4 

5 


Package-2 

F-18 

4 

4 
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TARGET DATABASE 


NAME ID LATITUDE LONGITUDE TARGET TYPE ON STATION 

TIME 


T-01 40 29 

T-02 43 03 

T-03 42 04 

T-04 T-04 41 00 

TEXACO-A 32 06 

TEXACO-B 27 03 

T-06 39 06 

T-07 40 46 

T-08 44 44 

T-09 38 38 

EYE-1 31 31 

C-1 33 33 

C-2 33 33 

C-3 33 33 

C-4 33 33 

CAP 2A 33 00 

T-10 40 32 

T-12 40 44 

T-13 39 25 

T-14 39 55 

T-15 40 12 

T-16 41 00 

T-17 40 21 

T-18 39 52 

T-19 39 35 

T-20 39 17 

T-21 38 45 

T-22 40 25 

T-24 41 00 

T-25 39 56 

T-26 39 24 

T-27 39 12 

T-28 40 13 

T-29 40 12 

T-30 41 00 

T-31 37 00 

T-32 37 05 

T-33 37 00 

T-34 37 03 


117 05 AFL 0 

115 30 BLDG . 0 

097 31 AFS 0 

101 32 HBUNK 0 

102 33 TANKER 480 

103 32 TANKER 480 

104 17 AFL 0 

107 16 AFL 0 

114 44 SAM 0 

115 55 AFS 0 

109 29 AEW 360 

110 00 CAP-IA 120 

110 00 CAP-IA 120 

110 00 CAP-IA 120 

110 00 CAP-IA 120 

095 00 CAP-IC 120 

117 15 BLDG 0 

117 31 POL 0 

117 03 ROAD-BRDG 0 

116 32 TLAM 0 

115 45 POL 0 

116 43 BLDG 0 

116 45 EW-NITE 0 

116 54 ROAD-BRDG 0 

116 41 AFS 0 

111 32 BLDG 0 

116 45 EW-NITE 0 

116 45 POL 0 

116 24 POL 0 

111 34 HBUNK 0 

116 45 ROAD-BRDG 0 

116 30 ROAD-BRDG 0 

116 29 TLAM 0 

115 56 SAM 0 

117 00 EW-NITE 0 

110 00 CAS 30 

117 15 CAS 30 

109 45 CAS 30 

110 10 CAS 30 
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APPENDIX C. FLIGHT SCHEDULES AND ATO INFORMATION t-ILE 

This appendix contains the flight schedules and ATO 
Information file created with the 8 period dataset. 


FLIGHT SCHEDULE BY LAUNCH TIME 


Launch Site Asset 


AIRBASE-01 F-117 

F-117 
F-117 

AIRBASE-02 F-15 
F-111 
F-111 
F-111 
F-15 
F-15 
F-15 
F-15 
F-15 
F-111 
F-15 
F-15 
F-15 
F-15 
F-15 

AIRBASE-03 KC-10 

AIRBASE-04 E-3A 

CV-65 A-6 

F-14 
A-6 
F-14 
F-14 
A-6 
A-6 


# Target Time 
ID onTop 


1 T-30 0230 

1 T-17 2215 

1 T-21 2245 

4 T-01 0720 

2 T-02 0800 

2 T-16 0829 

2 T-10 0920 

4 T-04 1045 

4 T-07 1030 

2 T-13 1045 

2 T-24 1130 

2 T-27 1215 

2 T-20 1340 

4 T-25 1440 

4 T-06 1530 

2 T-18 1600 

2 T-12 1715 

4 T-11 1615 

1 TEXACO-A 0630 

1 EYE-1 0630 

2 T-03 0800 

2 C-1 0700 

2 T-22 0940 

2 C-2 0900 

2 C-3 1100 

2 T-15 1220 

2 T-09 1425 


Launch Target 

Time Lat/Long 


0125 41 00 117 00 

2114 40 21 116 45 

2156 38 45 116 45 

0622 40 29 117 05 

0637 43 03 115 30 

0717 41 00 116 43 

0809 40 32 117 15 

0934 41 00 101 32 

0938 40 46 107 16 

0953 39 25 117 03 

1031 41 00 116 24 

1126 39 12 116 30 

1254 39 17 111 32 

1357 39 56 111 34 

1438 39 06 104 17 

1506 39 52 116 54 

1614 40 44 117 31 

1615 41 00 116 45 

0358 32 06 102 33 

0344 31 31 109 29 

0537 42 04 97 31 

0639 33 33 110 00 

0757 40 25 116 45 

0839 33 33 110 00 

1039 33 33 110 00 

1042 40 12 115 45 

1300 38 38 115 55 


64 



A-6 2 T-19 1530 1354 39 35 116 41 

A-6 2 T-29 1805 1627 40 12 115 56 

EA-6B 1 T-29 1805 1637 40 12 115 56 

A-6 2 T-08 2030 1815 44 44 114 44 

EA-6B 1 T-08 2030 1829 44 44 114 44 

MAG-01 A-10 4 T-31 0300 0232 37 00 110 00 

A-10 4 T-32 0500 0343 37 05 117 15 

A-10 4 T-33 0800 0731 37 00 109 45 

A-10 4 T-34 1000 0932 37 03 110 10 

F-18 2 T-26 1920 1827 39 24 116 45 

SSN-69 THAWK 2 T-28 0500 0231 40 13 116 29 

THAWK 2 T-14 1130 0904 39 55 116 32 


FLIGHT SCHEDULE BY TIME ON TARGET 


LAUNCH SITE ASSET # TARGET TIME LAUNCH TARGET 
ID ON TOP TIME LAT/LONG 


AIRBASE-01 F-117 1 T-30 0230 0125 41 00 117 00 

F-117 1 T-17 2215 2114 40 21 116 45 

F-117 1 T-21 2245 2156 38 45 116 45 

AIRBASE-02 F-15 4 T-OI 0720 0622 40 29 117 05 

F-111 2 T-02 0800 0651 43 03 115 30 

F-111 2 T-16 0829 0829 41 00 116 43 

F-111 2 T-10 0920 0821 40 32 117 15 

F-15 4 T-07 1030 0938 40 46 107 16 

F-15 4 T-04 1045 0934 41 00 101 32 

F-15 2 T-13 1045 0953 39 25 117 03 

F-15 2 Tr24 1130 1031 41 00 116 24 

F-15 2 T-27 1215 1126 39 12 116 30 

F-111 2 T-20 1340 1302 39 17 111 32 

F-15 4 T-25 1440 1357 39 56 111 34 

F-15 4 T-06 1530 1438 39 06 104 17 

F-15 2 T-18 1600 1506 39 52 116 54 

F-15 4 T-11 1615 1615 41 00 116 45 

F-15 2 T-12 1715 1614 40 44 117 31 

AIRBASE-03 KC-10 1 TEXACO-A 0630 0358 32 06 102 33 

AIRBASE-04 E-3A I EYE-I 0630 0344 31 31 109 29 

CV-65 F-14 2 C-1 0700 0639 33 33 110 00 

A-6 2 T-03 0800 0612 42 04 97 31 

F-14 2 C-2 0900 0839 33 33 110 00 
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2 T-22 0940 0823 40 25 116 45 

2 C-3 1100 1039 33 33 110 00 

2 T-15 1220 1107 40 12 115 45 

2 T-09 1425 1321 38 38 115 55 

2 T-19 1530 1418 39 35 116 41 

1 T-29 1805 1651 40 12 115 56 

2 T-29 1805 1651 40 12 115 56 

1 T-08 2030 1849 44 44 114 44 

2 T-08 2030 1849 44 44 114 44 

MAG-01 A-10 4 T-31 0300 0232 37 00 110 00 

A-10 4 T-32 0500 0343 37 05 117 15 

A-10 4 T-33 0800 0731 37 00 109 45 

A-10 4 T-34 1000 0932 37 03 110 10 

F-18 2 T-26 1920 1751 39 24 116 45 

SSN-69 THAWK 2 T-28 0500 0231 40 13 116 29 

THAWK 2 T-14 1130 0904 39 55 116 32 


FLIGHT SCHEDULE BY TARGET 


TARGET LAUNCH SITE ASSET # TIME on TARGET 

C-1 CV-65 F-14 2 - 0700 

C-2 CV-65 F-14 2 0900 

C-3 CV-65 F-14 2 1100 

EYE-1 AIRBASE-04 E-3A 1 0630 

T-01 AIRBASE-02 F-15 4 0720 

T-02 AIRBASE-02 F-111 2 0800 

T-03 CV-65 A-6 2 0800 

T-04 AIRBASE-02 F-15 4 1045 

T-06 AIRBASE-02 F-15 4 1530 

T-07 AIRBASE-02 F-15 4 1030 

T-08 CV-65 A-6 2 2030 

CV-65 EA-6B 1 2030 

T-09 CV-65 A-6 2 1425 

T-10 AIRBASE-02 F-111 2 0920 

T-11 AIRBASE-02 F-15 4 1615 

T-12 AIRBASE-02 F-15 2 1715 

T-13 AIRBASE-02 F-15 2 1045 

T-14 SSN-69 THAWK 2 1130 

T-15 CV-65 A-6 2 1220 

T-16 AIRBASE-02 F-111 2 0829 

T-17 AIRBASE-01 F-117 1 2215 

T-18 AIRBASE-02 F-15 2 1600 

T-19 CV-65 A-6 2 1530 

T-20 AIRBASE-02 F-111 2 1340 

T-21 AIRBASE-01 F-117 1 2245 

T-22 CV-65 A-6 2 0940 


A-6 

F-14 

A-6 

A-6 

A-6 

EA-6B 

A-6 

EA-6B 

A-6 
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T-24 AIRBASE-02 F-15 2 1130 

T-25 AIRBASE-02 F-15 4 1440 

T-26 MAG-01 F-18 2 1920 

T-27 AIRBASE-02 F-15 2 1215 

T-28 SSN-69 THAWK 2 0500 

T-29 CV-65 A-6 2 1805 

CV-65 EA-6B 1 1805 

T-30 AIRBASE-01 F-117 1 0230 

T-31 MAG-01 A-10 4 0300 

T-32 MAG-01 A-10 4 0500 

T-33 MAG-01 A-10 4 0800 

T-34 MAG-01 A-10 4 1000 

TEXACO-A AIRBASE-03 KC-10 1 0630 

ATO INFORMATION 


ALL TARGETS WERE ASSIGNED 


END OF PERIOD INVENTORY 


CV-65 

A-6 

F-14 

F-18 

E-2 

EA-6B 


T1 T2 T3 T4 T5 T6 T7 T8 

12 10 8 8 6 6 8 12 

12 12 8 10 12 12 12 12 

20 20 20 20 20 20 20 20 


AIRBASE-02 

F-15 

F-111 


10 10 10 10 10 10 


MAG-01 

A-10 

F-18 


12 12 12 12 12 12 10 12 
10 10 10 10 12 12 12 12 
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LAUNCH SITE 


ASSET 


AIRBASE-01 F-117 3 

AIRBASE-02 F-111 8 

F-15 34 

AIRBASE-03 KC-10 1 

AIRBASE-04 E-3A 1 

CV-65 A-6 14 

EA-6B 2 

F-14 6 

MAG-01 A-10 16 

F-18 2 

SSN-69 THAWK 4 

TOTAL SORTIES FLOWN = 91 


ESTIMATED GAS (in pounds) REQUIRED FOR AIR REFUELING 46000 
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